IBX-11181: Filtered client-supplied X-Forwarded-* headers in Varnish VCL - #13
IBX-11181: Filtered client-supplied X-Forwarded-* headers in Varnish VCL#13vidarl wants to merge 2 commits into
Conversation
| @@ -0,0 +1,44 @@ | |||
| # Image for running the varnishtest suite in tests/varnish/. | |||
There was a problem hiding this comment.
@micszo
I need to include new Dockerfile for varnish here ( and in post-install too) which is almost carbon copy of https://github.com/ibexa/docker/blob/v4.6.31/docker/Dockerfile-varnish
I suggest we change the structure of the varnish image in order to make it more general and re-usable. However, that would imply a BC break so not sure if we can do it before 6.0, or if this docker files are "supported" and BC guaranteed .
What I suggest is: In ibexa/docker we could:
- Remove the
COPYlines ofdefault.vclandparameters.vcl- So this is not part of the image itself - Change so that
varnish.ymlcontain the basic common configuration needed for varnish container - Change so that
varnish.ymlusesimage:instead ofbuild: - change
varnish7.yml( and in near futurevarnish9,yml) so that they are overlays for varnish.yml, only containing version specific information ( including volumes to mount the vcls an referencing varnish7 image ) - We add job in docker to push images to ghcr.io, as we already do for PHP images.
- CI in
ibexa/cloudandibeax/post-installcan then create varnish container without duplicated dockerfile
It is a lot of things to do for just removing some duplicated code though ( but keep in mind that it is not only here in ibexa/cloud and ibeax/post-install we get rid of duplicated code). The Dockerfile-varnish* and varnish*.yml files in ibexa/docker also contains a lot of duplicated code
BC breaks are:
- varnish.yml will use volumes to load vcl files.
- varnish.yml will use
image:instead ofbuild
If varnish files doc/docker are used as-is, no problem. However, this might break local workflows and customizations.
1 participant
Related PRs:
Description:
Follow-up to ibexa/core#699, which makes Ibexa DXP declare the peer a trusted proxy when a request
arrives via Fastly on Ibexa Cloud. Once trusted proxies are in play, every
X-Forwarded-*header aclient sends is believed by Symfony, so the VCL has to stop them from reaching the application.
Same change as ibexa/post-install#108, applied to the Upsun 5.0 VCL.
Per the Upsun header documentation the
router is authoritative for
X-Forwarded-Proto,X-Client-IPandClient-Cdn, and discardswhatever the client sent for them. It says nothing about
X-Forwarded-Host,X-Forwarded-PrefixorRFC 7239
Forwarded, and states that it otherwise passes request headers through - so those threearrive client controlled and are now stripped.
X-Forwarded-Forneeded more care. Without a CDN the router only appends the real client IP towhatever the client sent, so every leading entry is client controlled.
X-Client-IPis authoritativein both the CDN and the non-CDN case, so it becomes the sole value of
X-Forwarded-For. If it isabsent the request did not come through the router at all, and the header is dropped.
For QA:
Confirm on a real Upsun environment that a client supplied
X-Forwarded-Hostno longer reaches theapplication, and that
Client-Cdn: fastlyfrom the router still does.